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1 Description 

2 Method for diagnosis of driver outputs and diagnosis pulse manager 
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3 The invention relates to a method for diagnosis of driver outputs, especially for 

4 use in a motor vehicle, in which, for reading out a diagnosis result at a driver 

5 output, a pulse is fed to the driver output. 

6 The invention further relates to a diagnosis pulse manager for feeding pulses to 

7 driver outputs depending on system requirements, especially for use in a motor 

8 vehicle to read out diagnosis results at driver outputs. 

9 The monitoring of final stage driver outputs within the context of an error diagnosis 

10 during operation of a motor vehicle is known. To obtain clear diagnosis results in 

1 1 certain switching states it is necessary to actively feed a pulse to a final stage 

12 driver output. The system requests the supply of such a pulse. 

13 In this context it is problematic, if a pulse requirement is present for a plurality of 

14 driver outputs simultaneously, especially if, for system reasons, a pulse cannot be 

15 provided simultaneously for all driver outputs. This is the case for example when 

16 the system only makes one timer functionality available. 

17 The object of the invention is to provide a method and a diagnosis pulse manager, 

18 so that when pulses are required simultaneously for a number of driver outputs, a 

19 reliable error diagnosis can be undertaken. 

20 This object is achieved with the features of the independent claims. 

21 Advantageous embodiments of the invention are specified in the dependent 

22 claims. 

23 The invention builds on the generic method by enabling an existing requirement of 

24 a pulse for a driver output to be stored, with especially a plurality of 

25 simultaneously existing requirements able to be stored, and by enabling a number 

26 of stored requirements to be taken into consideration successively according to 

27 predetermined rules. This means that if there are a plurality of requirements for 
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1 pulses it is not necessary only to explicitly take account of one of these 

2 requirements and to discard the other requirements. Instead the requirements can 

3 be stored and taken into account in tum in accordance with predetermined rules. 

4 The method is advantageously developed by the requirements being able to be 

5 stored as binary values in a diagnosis pulse requirement register, by the 

6 requirements stored in the diagnosis pulse requirement register being able to be 

7 transmitted to a diagnosis pulse execution register and by the diagnosis pulse 

8 requirement register being cleared after the requirements have been transmitted 

9 into the diagnosis pulse execution register. The system requirements can thus be 

10 stored initially In a diagnosis pulse requirement register and then, depending on 

1 1 processes in the past or on other criteria respectively, be transferred into a 

12 diagnosis pulse execution register. After transfer of the information the diagnosis 

13 pulse requirement register can be erased in order to enable new system 

14 requirements to be taken into consideration in the next cycle. 

15 Usefully there is provision for the requirements only to be transferred from the 

16 diagnosis pulse requirement register to the diagnosis pulse execution register if no 

17 requirements are stored in the diagnosis pulse execution register. Otherwise a 

18 requirement stored in the diagnosis pulse execution register which is the next to 

19 be executed, is first converted into a pulse to be executed at the assigned driver 

20 output. 

21 Furthermore it is useful, before the transmission of the requirements from the 

22 diagnosis pulse requirement register into the diagnosis pulse execution register, to 

23 delete from the diagnosis pulse requirement register requirements that are also no 

24 longer stored in the diagnosis pulse execution register. This takes account of 

25 whether conditions which might have obtained at one point in the past continue to 

26 obtain; Only if this is the case does the question of execution of the pulses at the 

27 corresponding driver output arise. 

28 The invention is advantageously developed in that, after a requirement stored in 

29 the diagnosis pulse execution register is taken into account, this request is deleted 

30 in the diagnosis pulse execution register. This means that, for a subsequent 
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1 request of the diagnosis pulse execution register, diagnosis pulses assigned to 

2 other driver outputs can be executed, provided corresponding requirements are 

3 stored in the diagnosis pulse execution register. 

4 It is preferred that the predetermined rules are based on at least one of the 

5 following criteria: Different driver outputs have a different priority, and a request 

6 assigned to a specific driver output may be taken into account or not. Where 

7 different priorities are taken into account the requirements assigned to the higher- 

8 priority driver outputs are considered first. For example there can be provision for 

9 the driver channels to be prioritized in the order of their ordinal number. In the 

10 case of the other criterion as to whether a requirement assigned to a specific 

1 1 driver output may be taken into account or not, there can be provision, depending 

12 on other conditions, for entirely excluding required pulses from being applied to 

13 specific driver outputs. 

14 Usefully there is provision for the priorities of the driver outputs to be defined by 

15 configuration of a control and prioritization unit. This can for example influence 

16 whether positions in the registers are actually to be written or deleted. 

17 It is especially of advantage for the priorities of the driver outputs to change 

18 dynamically depending on the operating states of the motor vehicle. For example 

19 the evaluation of specific driver outputs can be especially useful at high speeds, 

20 said outputs only being of secondary interest on the other hand at lower speeds. 

21 The invention builds on the generic diagnosis pulse manager by providing a 

22 diagnosis pulse requirement register for storing a requirement of a pulse which is 

23 present for a driver output, with especially a plurality of simultaneously existing 

24 requirements able to be stored, and by enabling a plurality of stored requirements 

25 to be successively taken into account according to predetermined rules. In this 

26 way the advantages and special features of the method in accordance with the 

27 invention can also be implemented within the framework of a diagnosis pulse 

28 manager. This then also applies to the especially preferred embodiments of the 

29 inventive diagnosis pulse requirement manager specified below. 

30 This is developed in a useful manner by the requirements in the diagnosis pulse 
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1 requirement register being able to be stored as binary values, by the requirements 

2 stored in the diagnosis pulse requirement register being able to be transmitted into 

3 a diagnosis pulse execution register and the diagnosis pulse requirement register 

4 being erased after transfer of the requirements into the diagnosis pulse execution 

5 register. 

6 Furthermore there is provision for the requirements only to be transferred from the 

7 diagnosis pulse requirement register into the diagnosis pulse execution register if 

8 no requirements are stored in the diagnosis pulse execution register. 

9 It is especially of advantage that, before the transmission of the requirements from 

10 the diagnosis pulse requirement register into the diagnosis pulse execution 

1 1 register, requirements no longer stored in the diagnosis pulse requirement register 

12 are also deleted in the diagnosis pulse execution register. 

13 Preferably there is also provision, after a requirement stored in the diagnosis 

14 pulse execution register has been taken into account, for this requirement to be 

15 deleted in the diagnosis pulse execution register. 

16 With the diagnosis pulse manager it is especially preferred that the predetermined 

17 rules are based on at least one of the following criteria: Different driver outputs 

18 have a different priority, and a requirement assigned to a specific driver output 

19 may be taken into account or not. 

20 In this case there is also provision for the priorities of the driver outputs to be 

21 defined by configuration of a control and prioritization unit. 

22 The inventive diagnosis pulse manager is advantageously developed by the 

23 priorities of the driver outputs being able to change dynamically depending on the 

24 operating states of the motor vehicle. 

25 The invention is based on the knowledge that it is possible to ensure for 

26 simultaneous requirement of pulses for a plurality of driver outputs that all pulse 

27 requirements can be processed in a diagnosis pulse manager. In particular priority 

28 rules and control algorithms can be taken into account in this case. 
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1 The invention is now explained with reference to the accompanying drawings on 

2 the basis of preferred embodiments. 

3 The drawings show: 

4 Figure 1 a function block diagram to explain the present invention; 

5 Figure 2 a flowchart to explain the inventive procedure; and 

6 Figure 3 a diagram for explaining the flowchart shown in Figure 2 on the basis 

7 of a diagram. 

8 Figure 1 shows a function block diagram to explain the present invention. The 

9 central element shown in Figure 1 is a diagnosis pulse manager 10, This is 

10 confronted on one side with system requirements 12 and must on the other side 

1 1 take care of a pulse execution 22 which relates to different driver outputs 20. The 

12 diagnosis pulse manager 10 performs these tasks by requirement processing, 

13 which especially includes a diagnosis pulse requirement register 14, and 

14 execution processing which especially includes a diagnosis pulse execution 

15 register 16. Information is passed between requirement processing and execution 

16 processing by control and prioritization functions 18, so that there is a guarantee 

17 that attention is paid to the system requirements 12 in pulse execution 22, 

18 especially taking into account different criteria, a process which will be explained 

19 below with reference to different examples. 

20 Figure 2 shows a flowchart to explain the inventive method. A general execution 

21 sequence of the method in accordance with the invention is first explained which 

22 occurs after the start of the method in step S1 with a fixed repetition rate. In step 

23 S2 a check is performed as to whether diagnosis pulses are currently required. If 

24 this is not the case, a check is performed in step S2A as to whether diagnosis 

25 pulses have been required in the past. If this is not the case either, the execution 

26 sequence of the method returns to checking as defined in step S2. If however 

27 diagnosis pulses have been required in the past, the execution sequence goes 

28 from step S2A to step S4 which in the case in which diagnosis pulses are 

29 currently required (step S2), is reached via the step S3. In this step S3 the 
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1 currently required diagnosis pulse is stored in the diagnosis pulse requirement 

2 register "dlag_puls_anforder_reg". 

3 In step S4 a check is now perfomned as to whether the conditions for diagnosis 

4 pulses required in the past continue to be fulfilled. If this is not the case, in 

5 accordance with step S5 the pulse requirement concerned is deleted in the 

6 diagnosis pulse execution register "diag_puls_ausfuhr_reg" and in the diagnosis 

7 pulse requirement register. After this, or if the conditions for the diagnosis pulse 

8 required in the past respectively continue to be fulfilled however, a check is 

9 performed in step S6 as to whether all diagnosis pulses required in the past are 

10 already executed, meaning whether the following applies for the diagnosis pulse 

1 1 execution register: diag_puls_ausfuhr_reg == 0. If this is the case, in step S7 

12 newly required diagnosis pulses are transmitted from the diagnosis pulse 

13 requirement register into the diagnosis pulse execution register, meaning that the 

14 diagnosis pulse requirement register is copied into the diagnosis pulse execution 

15 register (diag_puls_ausfuhr_reg = diag_puls_anforder_reg). Subsequently in step 

16 S8 the diagnosis pulse requirement register is erased 

17 (diag_puls_anforder_reg = 0). 

18 Subsequently in step S9 the next diagnosis pulse is activated and in the diagnosis 

19 pulse execution register the pulse requirement concerned is deleted. Step S9 can 

20 also be reached directly, starting from step S6, if not all diagnosis pulses required 

21 in the past are already executed. In this case the next diagnosis pulse is activated 

22 and the corresponding location in the diagnosis pulse execution register is erased 

23 for the diagnosis pulses required in the past. After step S9 the functional 

24 sequence returns to step S2 or ends at step S10 respectively. 

25 Figure 3 shows a diagram to explain the flowchart shown in Figure 2 on the basis 

26 of an example. Different executions sequence for different scenarios or system 

27 requirements are explained with reference to this diagram In step S2, at point in 

28 time n, new diagnosis pulses are required, namely for the driver outputs 1 , 2 and 

29 8. Consequently the question asked in step S2 in accordance with Figure 2 is 

30 answered with "yes" and the execution sequence goes to step S3. 
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1 In step S3, through the mediation the prioritization and control unit, the currently 

2 required pulse is stored in the diagnosis pulse requirennent register. In the case 

3 shown in the example the register locations 1 , 2 and 8 are thus set to the value 1 

4 with the active setting of the register locations in the diagram shown in 

5 accordance with Figure 8 being identified by these register locations being 

6 shaded. 

7 Subsequently in step S4, the question is asked whether the conditions for 

8 diagnosis pulses which may have been required in the past continue to be fulfilled. 

9 Since in the present example there are no diagnosis pulses which were required 

10 in the past, the answer to the question should be "y©s" so that the method moves 

1 1 to step S6 from step S5 without taking any action. Step S6 then checks whether 

12 the following applies: diag_puls_ausfuhr_reg == 0. In the case in which diagnosis 

13 pulses have already been required in the past, this means that these have also 

14 already been executed. In the example shown here the diagnosis pulse execution 

15 register is fully in state 0, since this is its initial state. The question in accordance 

16 with step S6 is thus answered with a "yes" so that in step S7 the newly required 

17 diagnosis pulses can be transferred from the diagnosis pulse requirement register 

18 to the diagnosis pulse execution register. This is done under the mediation of the 

19 prioritization and control unit. 

20 Subsequently in step S8 the diagnosis pulse requirement register is erased. 

21 In step S9 the next diagnosis pulse Is activated and the corresponding pulse 

22 requirement is deleted in the diagnosis pulse execution register. In the present 

23 example the location in the diagnosis pulse execution register with the highest 

24 priority is the location which is assigned to the driver output with the highest 

25 ordinal number. 

26 The execution sequence of the method then returns to step S2 in order to react to 

27 the system requirements present at point in time n+1 . In the present example new 

28 diagnosis pulses are again required, namely here again for the driver outputs 1 , 2 

29 and 8. The question in step S2 is thus answered with "yes" and the execution 

30 sequence of the method goes to step S3. Since the value for the driver output 8 in 
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1 the diagnosis pulse execution register at point in time n was set in step S9 to 0, 

2 this value is set in step n+1 back to 1 by contrast with the locations corresponding 

3 to the driver outputs 1 and 2 in the diagnosis pulse request register, since these 

4 are still set to 1 in the diagnosis pulse execution register. 

5 In step S4 a check is subsequently made as to whether the conditions for 

6 diagnosis pulses required in the pasf continue to be fulfilled. Since this is the case 

7 - diagnosis pulses continue to be required for the driver outputs 1 , 2 and 8 - the 

8 execution sequence immediately goes to step S6 in which a check is made as to 

9 whether all the diagnosis pulses required in the past have been executed. This 

10 question is answered at point in time n+1 with "no" since the diagnosis pulses 

1 1 required for the first driver output and the second driver output have not yet been 

12 executed. The method consequently goes to step S9 where the next diagnosis 

13 pulse in the priority sequence is executed, namely the diagnosis pulse for the 

14 second driver output. 

15 The method subsequently returns to step S2 where a check is performed as to 

16 whether diagnosis pulses are currently required. This question is answered with 

17 "yes" since at point in time n+2 a diagnosis pulse is required for driver output 2. 

18 Subsequently in step S3 the currently required diagnosis pulse is stored at the 

19 corresponding location in the diagnosis pulse requirement register. 

20 Subsequently in step S4 a check is performed as to whether the conditions for 

21 diagnosis pulses required in the past continue to be fulfilled. This is only partly the 

22 case, namely for driver output 2 and not for driver outputs 1 and 8, so that the 

23 question must be answered with "no" overall. Subsequently the execution 

24 sequence of the method goes to step S5 where the corresponding locations are 

25 deleted in the diagnosis pulse execution register and in the diagnosis pulse 

26 requirement register. This relates in the diagnosis pulse requirement register to 

27 the locations 1 and 8 while in the diagnosis pulse execution register, because of 

28 the pulse execution already undertaken at the eighth driver output, only the 

29 location which corresponds to the first driver output will have to be set to 0. 

30 In step S6 a check is performed as to whether all diagnosis pulses required in the 
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1 past have been executed. This is the case since the diagnosis pulse execution 

2 register is completely set to 0. The method subsequently goes to step S7 and the 

3 state of the diagnosis pulse requirement register is transferred to the diagnosis 

4 pulse execution register. 

5 Subsequently in step S8 the diagnosis pulse requirement register is erased. 

6 in step S9 the only pulse to be executed in accordance with the diagnosis pulse 

7 execution register is executed for the second driver output and the corresponding 

8 location in the diagnosis pulse execution register is deleted. 

9 Without this always having been pointed out above, the modifications in the 

10 registers are frequently undertaken under the mediation the prioritization and 

11 control unit, a fact which is indicated in the diagram shown in Figure 3 by the 

12 arrows representing the influencing of the register locations having to pass 

13 through the boxes identified by a broken line symbolizing the prioritization and 

14 control unit 18. 

15 Thus the invention can be summarized as follows: A method is specified for 

16 diagnosis of a driver outputs 20 and a diagnosis pulse manager 10 which are able 

17 to feed to a driver output 20 a pulse in order to perform a diagnosis of this driver 

18 output. Since the system requirements 12 and can turn out so that simultaneously 

19 a plurality of diagnosis pulses are required, a diagnosis pulse requirement register 

20 14 and a diagnosis pulse execution register 15 are provided so that the plurality of 

21 requirements existing simultaneously 12 can be stored. On the basis of this 

22 buffering of requirements 12 it is possible for a number of stored pulse 

23 requirements to be taken into consideration successively in accordance with 

24 predetermined rules. 

25 



